System and method for authentication to an application

ABSTRACT

Authenticating a first user in a protected network to an application in a DMZ network shared simultaneously with a second user in an unprotected network. The first user supplies a userID and a password to a first server within the protected network for authentication for the application. The first sewer checks authentication of the first user based on the userID and password. If the first user is authentic, the first server forwards to the application an authentication key for the first user and a selection by the first user pertaining to the application. The application checks authentication of the key, and if authentic, complies with the selection by the first user. The second user supplies another userID and another password to the application. If the other userID and other password are authentic, the application complies with a selection made by the second user pertaining to the application.

FIELD OF THE INVENTION

The invention relates generally to computer networks, and deals moreparticularly with a technique to authenticate users from a protectedintranet and unprotected network to a shared application.

BACKGROUND OF THE INVENTION

Communications often flow from one network to another, and usually someform of security is required between the networks. Security is oftenprovided by user identifications or userIDs and passwords toauthenticate a user, and a firewall to screen out unwanted messages.There are different types of networks, and the type of security dependson the types of networks involved in the communication. For example,there may be an intranet or “Blue zone” for local communications withinan enterprise. It is presumed that all users of the intranet aretrustworthy because they all work for the same enterprise. Therefore,usually there is relatively little security concern within the intranet,although userIDs and passwords are still required to accessapplications. However, oftentimes users of the intranet want tocommunicate with another entity located on another network, for example,a “Red zone” such as the Internet. Because this other entity may notwork for the enterprise, and this other network is not under control ofthe enterprise, this other entity and network cannot be thoroughlytrusted. It is possible that a user on this other network can attempt tolearn a userID and password of a user within the firewall and then,using this userID and password, view or tamper with sensitive datawithin the firewall. Therefore, a firewall may be installed at thegateway to the intranet. The firewall is responsible for enforcing asecurity policy for incoming communications. This security policy maydefine which types of networks that the intranet is permitted tocommunicate and what protocols are permitted for the communications. Thefirewall also may (a) limit incoming traffic to certain source IPaddresses and through certain firewall ports, (b) limit outgoing trafficto certain destination IP addresses and through certain firewall ports,and (c) detect viruses to thwart hackers.

For additional security, the enterprise that controls and uses the Bluezone intranet may also create and control a “Demilitarized zone” (“DMZ”)or “Yellow zone” between the Blue zone and the Red zone. The Yellow zonewould include one or more servers and respective data bases managed bythe enterprise. However, the Yellow zone data bases typically would notinclude sensitive data or the only copy of sensitive data. Therefore, ifthe server(s) in the enterprise's DMZ are corrupted by a communicationfrom another network, the damage is repairable. The firewall for theenterprise's intranet or Blue Zone may only permit communications withthe enterprise's “Yellow Zone”. The management of the servers andrelated devices in the enterprise's DMZ allows the enterprise a measureof security in the enterprise's DMZ. Therefore, the Yellow zone servesas a buffer for the Blue zone. The enterprise's DMZ may be authorized tocommunicate with an untrusted server or workstation in the “Red zone”directly or through another firewall. It is also possible to connect theenterprise's intranet with its firewall directly to one or moreuntrusted networks in a Red zone, and rely on the enterprise intranet'sfirewall to provide security.

Some applications support simultaneous participation from users locatedwithin a Blue zone and a Red zone. For example, an existing e-meetingapplication executes in a Yellow zone of a host enterprise and mayinvolve participants from different companies. The participants from thehost enterprise are in the Blue zone and the other participants are inthe Red zone and access the e-meeting application. Currently, all theusers, regardless of their location, must log-on with a userID andpassword. While this is effective in authenticating the users to theapplication, there is the potential for a hacker in the Red zone tolearn the userID and password of a user in the Blue zone. With thisuserID and password, it would then be possible for the hacker to accesssensitive data within the Blue zone.

Accordingly, an object of the present invention is to shield the Bluezone users' passwords from the Red zone users who can simultaneouslyaccess the same application in the Yellow zone.

SUMMARY OF THE INVENTION

The invention resides in a system, method and program product forauthenticating a first user in a protected network to an applicationshared simultaneously with a second user in an unprotected network. Thefirst user supplies a userID and a password to a first server within theprotected network for authentication for the application. Theapplication resides in a third network. The first server checksauthentication of the first user based on the userID and password. Ifthe first user is authentic, the first server forwards to theapplication an authentication key for the first user and a selection bythe first user pertaining to the application. The application checksauthentication of the key, and if authentic, complies with the selectionby the first user.

According to one feature of the present invention, the protected networkand the third network are both controlled by a same entity.

According to another feature of the present invention, the second usersupplies another userID and another password to the application. If theother userID and other password are authentic, the application complieswith a selection made by the second user pertaining to the application.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram of three, interconnected networks (Blue zone,Yellow zone and Red zone), and servers in a Blue zone network and aYellow zone network which embody the present invention.

FIG. 2 is a flow chart illustrating a process for a server in the Bluezone to be authenticated to a server in the Yellow zone, and exchangeinformation pursuant to the present invention.

FIGS. 3(A), 3(B) and 3(C) form a flow chart illustrating a process for auser in the Blue zone to be authenticated with and use an application inthe Yellow zone.

FIGS. 4(A) and 4(B) form a flow chart illustrating a process for a userin the Red zone to be authenticated with and use an application in theYellow zone.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to the drawings in detail wherein like reference numbersindicate like elements, FIG. 1 illustrates intranet or Blue Zone network12, DMZ or Yellow zone network 14 and internet or Red zone network 16.The Blue zone is connected to the Yellow zone through a firewall 18.Firewall 18 protects the Blue zone against unwanted incursions from theYellow zone. The Yellow zone is connected to the Red zone through afirewall 19. Firewall 19 protects the Yellow zone against most unwantedincursions from the Red zone and monitors outgoing traffic. Firewall 18and Firewall 19 are responsible for enforcing a security policy forincoming communications. This security policy may define which types ofnetworks that the intranet is permitted to communicate and whatprotocols are permitted for the communications. The firewalls also may(a) limit incoming traffic to certain source IP addresses and throughcertain firewall ports, (b) limit outgoing traffic to certaindestination IP addresses and through certain firewall ports, and (c)detect viruses to thwart hackers.

Blue zone network 12 comprises a server 20, connectivity hardware andsoftware for intranet 22 and a multiplicity of work stations connectedto the intranet 22. One such work station 24 and its user 25 areillustrated in FIG. 1. By way of example, the intranet 22 can utilizeHyper Text Transfer Protocal (“HTTP”), File Transport Protocol (“FTP”),User Datagram Protocol (“UDP”), Transmission Control Protocol/InternetProtocol (“TCP/IP”), IBM Lightweight Directory Access Protocol (“LDAP”)or other IP protocols. By way of example, the user of work station 24interacts with application 28 using HTTP protocol. Server 20 within theBlue zone is executing an application 28 which, as described below,participates in authenticating the user 25 within the Blue zone to adual or multi-network application 30 within the Yellow zone. Application28 can interact with application 30 using HTTP protocol.

Yellow zone network 14 comprises a server 40, and connectivity hardwareand software 42 and 44 for the Blue zone and the Red zone, respectively.By way of example, the connectivity hardware and software 42 and 44 canutilize HTTP, FTP, UDP, TCP/IP, IBM LDAP or other IP protocols. Server40, within the Yellow zone, is executing dual or multi-networkapplication 30. As described below, application 30 participates inauthenticating the user 25 within the Blue zone to application 30 andparticipates in authenticating a user 53 within the Red zone toapplication 30. Application 30 also provides a dual or multi-networkfunction such as an electronic meeting (“e-meeting”) function wheredifferent users simultaneously view a presentation of screens made by aleader, and simultaneously listen over the telephone to a verbalpresentation related to the screen presentation. Typically (but notalways), the leader resides in the Blue zone along with otherparticipants, and the presentation screens are stored in the Blue zone.Typically also, the leader schedules the meeting and specifies who canparticipate in the meeting. Alternately, application 30 can provide ane-commerce function where users/exploiters from different zones canindependently view products and or information such as pricing andordering screens. Alternately, application 30 can provide typicalinteractive web application functions to users/exploiters from any zoneprovided they have been properly authenticated. Each of these functionssupports participants from the Blue zone and or Red zone in either acommon activity or when interacting independently with an application.

Red zone network 16 can be the internet/World Wide Web and comprisesmultiple servers and workstations. One such work station 52 and its user53 are illustrated. None of the Red zone servers is shown because, inthe illustrated embodiment, work station 52 can interact directly withYellow zone server 40 via internet 54. However, if desired a Red zoneserver can be interposed between work station 52 and Yellow zone server40 and serve as a conduit. By way of example, work station 52 interactswith Yellow zone server using HTTP protocol, although other protocolscan be used as well.

FIG. 2 is a flow chart illustrating a process for a server in the Bluezone to be authenticated to a server in the Yellow zone, and exchangeinformation pursuant to the present invention. In step 70, application28 on Blue zone server 20 requests that it be authenticated toapplication 30 on Yellow zone server 40. This request is made by a keyfile exchange. This is done by the administrators when the servers areinitially set up, so that not only does the Blue zone server identifyitself to the Yellow zone server, but the Yellow zone server identifiesitself to the Blue zone server. This cross challenge proves to eachserver the identity of the other server when the application is running.Application 30 checks the authentication by confirming the request isfrom a trusted source by decrypting the request with the key previouslyexchanged (decision 74). If the authentication fails, then application30 notifies application 28, and application 28 notifies user 25 throughnormal failure messages (step 76). However, if the authenticationsucceeds, then application 28 can request a list of e-meetings scheduledfor the day (or some other period of time) (step 80). In response tothis request, application 30 will return a list of e-meetings and theauthorized participants for each meeting. In the illustrated embodiment,application 30 also furnishes to application 28 an authentication key tobe used subsequently by application 28 when user 25 requestsparticipation in the e-meeting (step 82). (Alternately, as describedbelow, the authentication key can be self authenticating based on itscontent, and need not be supplied previously from application 30.) Afterreceiving the list of e-meetings and the authorized participants,application 28 can make this list available to the user to review (step86). The user 25 may also receive by e-mail, an electronic meetingnotice to learn of an e-meeting for which user 25 is authorized andrequested to participate.

FIG. 3(A) illustrates a process to authenticate a user (such as user 25on work station 24) in the Blue zone to application 28 on server 20 inthe Blue zone. As explained below with reference to FIG. 3(B), afterthis authentication to application 28, application 28 will authenticatethe user 25 to application 30 in the Yellow zone server 40 by furnishingto application 30 an authentication key. Referring again to FIG. 3(A),initially the user 25 selects an icon or intranet URL to invokeapplication 28 using HTTP (step 100). In response, application 28prompts the user 25 for a conventional userID and password (step 101),and the user 25 complies (step 102). Then, application 28 checks thecombination of userID and password against a list in a data base(decision 104). If the combination fails (decision 105), the user is sonotified to try again (step 106). If the combination passes, then theuser is considered authentic to application 28. In the case whereapplication 28 is an e-meeting application, application 28 then promptsthe user to select an e-meeting hosted by application 30 on server 40 inthe Yellow zone to join (or select another application on server 40 toaccess) (step 107). The user 25 can now make the selection and thisselection is temporarily stored in server 20 (step 108).

FIG. 3(B) illustrates the subsequent steps of application 28authenticating user 25 in the Blue zone to application 30 in the Yellowzone. After the foregoing authentication of user 25 to application 28with the userID and password, application 28 “builds” an authenticationkey 112 for user 25 and sends this key to application 30 along with theuser 25 selection of the e-meeting to join (step 110). In theillustrated embodiment, this key includes the foregoing key supplied byapplication 30 to application 28 in step 82 of FIG. 2), along with theuserID. This key obviates the need for application 28 to authenticateuser 25 to application 30 so that the password of user need not be sentto application 30. By avoiding the need to send the password of user 25into the Yellow zone, this prevents hackers in the Red zone fromobtaining the password of user 25 by hacking into the Yellow zone server40. The authentication key 112 may also contain information as to theidentity of the e-meeting that the user wishes to join, a length of timeduring which the key is valid, and an IP address of user 25. Also, theauthentication key can be encrypted. In the illustrated embodiment,application 28 was authenticated to application 30 and theauthentication key was supplied from application 30 to application 28beforehand, as illustrated in FIG. 2. However, optionally, the key sentfrom application 28 to application 30 in step 110 can be selfauthenticating based on the identity of the e-meeting that the userwishes to join, whether the period during which the key is valid matchesthe scheduled time of selected e-meeting, and whether the IP address ofuser 25 is from the Blue zone. If the key is considered selfauthenticating, then it need not be supplied from application 30 toapplication 28 in step 82, and the steps of FIG. 2 need not be performedat all. In step 114, application 30 checks the authentication of the keyeither by comparing the key to the key(s) supplied to application 28 instep 82 or checking the self authentication aspects. If the key is notauthentic (decision 116), then application 30 notifies application 28which handles the error, possibly by supplying another key or notifyingthe user of the problem (step 118). However, if the key is authentic,then application 30 joins user 25 to the meeting (or grants user 25access to another application on server 40 as requested by the user 25in step 108) (step 124 of FIG. 3(C)). Application 30 joins user 25 tothe e-meeting by furnishing to the user 25 (along with the otherauthenticated participants) the presentation screens. After being joinedto the meeting, user 25 can then participate in the meeting (126). Inthe case of a user who is not the leader, the user 25 participates byviewing the presentation screens on workstation 24 as they are chosenand advanced by the leader. The user also listens by telephone to averbal presentation related to the presentation screens. In the case ofa user who is the leader, the leader is originally “joined” to thee-meeting by setting up and scheduling the meeting. The set up includesa specification of which users are invited/authorized to participate inthe meeting. Subsequently, during the actual meeting, the leaderparticipates by selecting which screens are presented. The leader canalso delegate the leadership role to another user. The participants willlikely engage in verbal conversation during the presentation, and thisis carried over the voice telephone connection. Also, optionally, therecan be an IBM “Same Time” electronic connection or other messagingservice that any of the participants can use during the meeting to senda message in real time to another participant including the leader.

The leader, as a user, performed the steps illustrated in FIGS. 3(A),3(B) and 3(C) twice, once to setup and schedule the meeting and again tojoin the meeting when it occurs. Because this typically occurs duringdifferent times and sessions, the leader must be authenticated toapplication 28 and application 30 twice, so the steps of FIGS. 3(A),3(B) and 3(C) are typically performed twice for the leader.

FIGS. 4(A) and 4(B) illustrate a conventional process to authenticateuser 53 at work station 52 in the Red zone to application 30 in theYellow zone. Initially, user 53, with a web browser, invokes application30 either through a link or URL, for example, using HTTP protocol (step300). In response, application 30 prompts user 53 for a userID and apassword (step 302), and the user complies (step 304). Then, application30 checks the combination of userID and password against a list in adatabase (decision 306). If the authentication fails (decision 308),application 30 notifies the user 53 who can then try another combination(step 310). If the authentication succeeds (decision 308), thenapplication 30 prompts user 53 to select an e-meeting to join (or accessanother application on server 40 in the Yellow zone) (step 316). Inresponse, the user 53 selects an e-meeting to join (or anotherapplication to access), and workstation 52 sends this selection alongwith the userID to application 30 (step 320). Then, application 30checks the authority/right of user 53 to join the meeting by comparingthe userID to the list of authorized participants specified earlier bythe leader (step 322). If the user 53 is not authorized (decision 324),application 30 notifies workstation 52 which will display the error tothe user 53 (step 326). However, if the user 53 is authorized to jointhe e-meeting, then application 30 joins user 53 into the meeting (step330). Application 30 joins user 53 into the e-meeting by furnishing tothe user 53 (along with the other authenticated participants) thepresentation screens. Thereafter, user 53 can participate in thee-meeting by viewing the screen presentations (step 340). Also, user 53will likely join in a conference telephone call to listen to theassociated verbal presentation made by the leader, and converse with theleader if desired.

It is also possible for the leader of the e-meeting to reside in the Redzone, in which case the steps of FIGS. 4(A) and 4(B) would be performedtwice for the leader, once to set up and schedule the meeting and againto lead the meeting. In such cases, step 340 of FIG. 4(B) would bemodified accordingly.

Thus, one or more users in the Blue zone and one or more users in theRed zone can simultaneously participate in an e-meeting or otherapplication in the Yellow zone, and the passwords of the users in theBlue zone are not sent to the Yellow zone or the Red zone. This preventsusers from the Red zone, who have access to the Yellow zone but not theBlue zone, from learning the passwords of the users in the Blue zone.

Based on the foregoing, a technique to authenticate users from aprotected network and an unprotected network to a shared application hasbeen disclosed. However, numerous modifications and substitutions can bemade without deviating from the scope of the present invention.Therefore, the present invention has been disclosed by way ofillustration and not limitation, and reference should be made to thefollowing claims to determine the scope of the present invention.

1. A method for authenticating a first user in a protected network to anapplication shared concurrently with a second user in an unprotectednetwork, said method comprising the steps of: the first user supplying auserID and a password to a first server within said protected networkfor authentication for said application, said application residing in athird network configured as a buffer between said protected network andsaid unprotected network; said first server determining that said userIDand password are authentic, and in response, said first serverforwarding to said application an authentication key for said first userand a selection by said first user pertaining to said application, saidpassword not being sent from said protected network into said thirdnetwork to access said application; said application determining thatsaid key is authentic, and in response, said application complying withsaid selection by said first user; and said second user supplyinganother userID and another password to said application, saidapplication determining that said other userID and said other passwordare authentic, and in response, said application complying with aselection made by said second user pertaining to said application.
 2. Amethod as set forth in claim 1 wherein said application complies withsaid selection made by said second user without said second usersupplying an authentication key to said third network.
 3. A method asset forth in claim 1 wherein said protected network and said thirdnetwork are both controlled by a same entity.
 4. A method as set forthin claim 3 wherein said unprotected network is an Internet.
 5. A methodas set forth in claim 1 wherein said third network is a DemilitarizedZone (“DMZ”) network and acts as a security buffer for said protectednetwork.
 6. A method as set forth in claim 1 wherein said unprotectednetwork is an Internet.
 7. A method as set forth in claim 1 wherein saidselection by said first user is a request to said application, and saidselection by said second user is a request to said application.
 8. Amethod as set forth in claim 1 wherein said application is an electronicmeeting application, both said first user and said second userconcurrently participate in a same meeting, and said first user selectsa screen that is concurrently presented to both said first user and saidsecond user.
 9. A method as set forth in claim 8 wherein said selectionby said first user is a selection of an electronic meeting in which toparticipate.
 10. A method as set forth in claim 1 further comprising thestep of said application sending to said first server saidauthentication key before the step of said first server forwarding tosaid application said authentication key.
 11. A method as set forth inclaim 1 wherein said authentication key is self authenticating based onwhether a period during which the key is valid matches a scheduledperiod of use of said application, and whether an IP address of saidfirst user is from said protected network.
 12. An authentication systemcomprising: an application on a first server in a first network; asecond server in a second, protected network to receive from a firstuser within said second network a userID and a password forauthentication for said application, said second server including meansfor checking authentication of said first user based on said userID andpassword, and if said first user is authentic, forwarding to saidapplication an authentication key for said first user and a selection bysaid first user pertaining to said application, said password not beingsent from said protected network into said first network to access saidapplication; and said application including means for checkingauthentication of said key, and if authentic, complying with saidselection by said first user; and a workstation in a third, unprotectednetwork for a second user, said application being shared concurrentlywith said first and second users, said first network configured as abuffer between said second, protected network and said third,unprotected network; and wherein said application receives from saidsecond user another userID and another password, and includes means fordetermining that said other userID and other password are authentic, andin response, complying with a selection made by said second userpertaining to said application.
 13. A system as set forth in claim 12wherein said application complies with said selection made by saidsecond user without said second user supplying an authentication key tosaid first network.
 14. A system as set forth in claim 12 wherein saidfirst and second servers and said first and second networks are allcontrolled by a same entity.
 15. A system as set forth in claim 12wherein said first network is a Demilitarized Zone (“DMZ”) network andacts as a security buffer for said protected network.
 16. A system asset forth in claim 12 wherein said unprotected network is an Internet.17. A computer program product for authenticating a first user in aprotected network to an application shared simultaneously with a seconduser in an unprotected network, and authenticating said second user tosaid application, said program product comprising: a computer readablemedium; first program instructions, for execution on a first serverwithin said protected network, to receive from the first user a userIDand a password for authentication for said application, said applicationresiding in a third network configured as a security buffer between saidprotected network and said unprotected network; second programinstructions, for execution on said first server, to checkauthentication of said first user based on said userID and password, andif said first user is authentic, to forward to said application anauthentication key for said first user and a selection by said firstuser pertaining to said application, said password not being sent fromsaid protected network into said third network to access saidapplication; third program instructions in said application to checkauthentication of said key, and if authentic, comply with said selectionby said first user; fourth program instructions in said application toreceive from said second user another userID and another password,determine if said other userID and other password are authentic, and ifso, instruct said application to comply with a selection made by saidsecond user pertaining to said application; and wherein said first,second, third and fourth program instructions are recorded on saidmedium in functional form.
 18. A computer program product as set forthin claim 17 wherein said application complies with said selection madeby said second user without said second user supplying an authenticationkey to said third network.
 19. A method for authenticating a first userof a first computer in a protected network to a second computerexecuting an application, a second user of a third computer in anunprotected network and said first user of said first computerconcurrently sharing said application, said second computer residing ina third network configured as a buffer between said protected networkand said unprotected network; said method comprising the steps of: thefirst computer supplying a userID and a password of the first user to afourth computer in said protected network for authentication for saidapplication; said fourth computer determining that said userID andpassword are authentic, and in response, forwarding to said secondcomputer an authentication key for said first user, said password notbeing sent from said protected network into said third network to accesssaid application; said second computer determining that said key isauthentic, and in response, complying with a selection by said firstuser pertaining to said application; and said third computer supplyinganother userID and another password of said second user to said secondcomputer, said second computer determining that said other userID andsaid other password are authentic, and in response, said applicationcomplying with a selection made by said second user pertaining to saidapplication.
 20. A method as set forth in claim 19 wherein saidapplication complies with said selection made by said second userwithout said second user or said third computer supplying anauthentication key to said second computer or said third network.
 21. Amethod as set forth in claim 19 wherein said protected network and saidthird network are both controlled by a same entity.
 22. A method as setforth in claim 19 wherein said third network acts as a security bufferfor said protected network.